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REMARKS 

Applicant replies to the Final Office Action mailed on April 11, 2006. Applicant requests an 
Advisory Action, if necessary. Claims 1-8, 11, 19-20, 22-23, 27-28, and 36 were pending in the 
application and the Examiner rejects claims 1-8, 11, 19-20, 22-23, 27-28, and 36. Support for the 
amendments may be found in the originally-filed specification, claims, and figures. No new matter 
has been introduced by these amendments. Applicant asserts that the application is in condition for 
allowance and reconsideration of the pending claims is requested. 
Priority Claim 

As requested by the Examiner, Applicant has removed the priority claim from the 
application. In that regard, now that the application no longer claims priority, the objection to the 
Declaration is now moot. 

Rejections under 35 U.S.C. S 102 

The Examiner rejects claims 1-3, 7, 11, 27-28, and 36 under 35 U.S.C. § 102(e) as being 
anticipated by Kennedy et al, U.S. Patent No. '6,651,217 ("Kennedy"). Applicant respectfully 
traverses this rejection. 

Kennedy generally discloses a system and method for populating HTML form fields at a 
browser application. Specifically, Kennedy discloses that when a user first populates a form and 
submits it for processing, software running at the web browser determines whether the user has a 
stored profile containing information that is commonly used to complete forms. Such information 
may include, for example, first name, last name, street address, city, state, postal code, phone 
number, etc. If such a profile does not exist, the user is prompted as to whether or not he would like 
to create a profile. If the user chooses to create a profile, the Kennedy system extracts data from the 
form fields, matches each data item to a dictionary of commonly used fields, and user the data to 
construct the profile. When the user encounters subsequent forms, the Kennedy system attempts to 
match data from the user's profile to the appropriate form fields based on a mapping process. The 
Kennedy system then enters the matched data into the appropriate form fields. 

Significantly, the Kennedy system is entirely client based, in that creation of the user 
profile, mapping of profile items to form fields, and filling forms all takes place at the client 
computer. Applicant notes that the Examiner has stated that the "fill server", as disclosed in the 
claims of the instant application, is disclosed within Figure 6 of Kennedy. However, in reference to 
Figure 6, Kennedy recites that when "the user clicks on 'OK' and the values appearing in the 
autofill profile are stored in a data storage area such as area 206 of FIG, 2" (column 8, lines 43-45), 
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Figure 2 of Kennedy clearly illustrates that the "data storage area" is in the client computer. 
Kennedy makes no further reference to accessing a fill server that is separate from the client 
computer to store and retrieve profile data that is subsequently used to fill a form. As such, 
Kennedy does not disclose or suggest at least "obtaining the user profile from a fill server upon 
\py receiving a request from a client computer, wherein the fill server and the client computer are 
distinct devices," as similarly recited by independent claims 1 and 36. 

' Further, Kennedy discloses security measures that may be implemented to ensure that the 
user's profile data is not misused and/or compromised. For example, Kennedy discloses that 
"previously used data values are not used to populate a displayed form until the user affirmatively 
selects that choice" (column 7, lines 41-43). In other words, the Kennedy system prompts the user 
to determine whether or not to use the profile data to fill a form. Kennedy also discloses that, for 
additional security, "the values in data store 206 could be stored in encrypted form in a protected 
area in client computer 204" (column 7, lines 47-49). Thus, the profile data is protected from 
unauthorized use. 

The Internet is widely used, for example, to order products, participate in forums, download 
software, access email, read articles, view video, and the like. Therefore, many web sites require 
users to fill forms to participate in such activities. Some forms require authentication information 
such as a credit card number, social security number, driver's license number, etc. Others require 
very basic information such as name, address, email address, etc. Moreover, some sites are 
naturally more trustworthy than others. For example, if a user has repeatedly ordered products from 
a particular online store without incident, then that user may be more inclined to provide more 
personal information within a form for that online store. However, if the same user accesses a 
relatively unknown web site to receive a credit report, the user may be apprehensive about 
providing too much personal information. A user of the Kennedy system has two options for the 
above scenarios. First, the user may select not to have the form automatically filled and then 
proceed to fill in the form in the conventional manner. Second, the user may select to have the form 
automatically filled and then scour the form to delete information considered to be too personal. In 
other words, the Kennedy system lacks taxability to select which data elements from the user' 
profile to include in a form based on the type of form being filled. As such, Kennedy does not 
disclose or suggest at least, "configuring a security level to associate with the user data, wherein the 
security level associates a subset bf the user data to a form type" and "retrieving the subset of the 
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user data from the user profile based on the form type of the electronic form," as similarly recited 
by independent claims 1 and 36. 

Claims 2-3, 7, 11, and 27-28 variously depend from independent claim 1, and each 
dependent claim now incorporates numerous other dependent claims. As such, dependent 
claims 2-3, 7, 11, and 27-28 are differentiated from the cited reference for at least the reasons set 
forth above, as well as in view of their own respective features. 

Rejections under 35 U.S.C. § 103 

The Examiner rejects claims 4-6 under 35 U.S.C. § 103(a) as being unpatentable over 
Kennedy. Applicant respectfully traverses this rejection. 

As stated above in reference to the 35 U.S.C. § 102(e) rejection, Kennedy does not disclose 
or suggest at least "obtaining the user profile from a fill server upon receiving a request from a 
client computer, wherein the fill server and the client computer are not one in the same", 
"configuring a security level to associate with the user data, wherein the security level associates a 
subset of the user data to a form type" and "retrieving the subset of the user data from the user 
profile based on the form type of the electronic form," as recited by independent claims 1 and 36. 
Claims 4-6 variously depend from independent claim 1, and each dependent claim now 
incorporates numerous other dependent claims, so these dependent claims are differentiated 
from the cited reference for at least the reasons set forth above, as well as in view of their own 
respective features. 

The Examiner rejects claims 8, 19-20, and 22-23 under 35 U.S.C. § 103(a) as being 
unpatentable over Kennedy in further view of Markus et al, U.S. Patent No. 6,490,601 ("Markus"). 
Applicant respectfully traverses this rejection. 

Dependent claims 8, 19-20, and 22-23 variously depend from independent claim 1, and 
each dependent claim now incorporates numerous other dependent claims. As noted above, 
Kennedy does not teach or suggest each feature of amended independent claim 1 and Markus does 
not teach or suggest the missing features. Markus discloses a server for automatically filling in 
form fields of an electronic document by a user creating a profile. The profile contains information 
that would be commonly used to fill out an online form such as, for example, first and last name, 
address, telephone number, email address, credit card number, etc. However, Markus does not 
teach or suggest, "configuring a security level to associate with the user data, wherein the security 
level associates a subset of the user data to a form type" and "retrieving the subset of the user data 
from the user profile based on the form type of the electronic form," as recited by independent 
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claims 1. Thus, dependent claims 2-3 and 15 are differentiated from the cited references for at least 
the same reasons as above, as well as in view of their own respective features. 

Applicant respectfully submits that the pending claims are in condition for allowance. 
Reconsideration of the application is thus requested. The Commissioner is hereby authorized to 
charge any fees which may be required, or credit any overpayment, to Deposit Account No. 19- 
2814. Applicant invites the Examiner to telephone the undersigned if the Examiner has any 
questions regarding this Reply or the present application in general. 

Respectfully suWitted- * 



SNELL & WILMER L.L.P. 

400 E. Van Buren 

One Arizona Center 

Phoenix, Arizona 85004 

Phone: 602-382-6228 

Fax: 602-382-6070 

Email: hsobelman@swlaw.com 



Dated: July 10. 2007 




Howard ^Sobetman 
Reg. No. 39,038 
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enter a user ID 96 and a field to enter a password 98. The login portion 94 allows a 
user to access their specific user profile from any WWW browser having access to 
the fill server URL. The login/registration screen 95 also includes a new registration 
portion 92 which allows a user to utilize create a new user profile. 

With continued reference to FIGURE 8, at decision block 804, a 
determination is made whether the user wishes to create a new user profile or access 
an existing user profile. With reference to FIGURE 9, such a determination can be 
made by whether the user enters an ID and a password at the login portion 94, or 
whether the user clicks on the new registration portion 92. If at block 804 the user 
wishes to create a new user profile, a new account registration icon 92 (FIGURE 9) is 
selected at block 806 and the fill sever application window on the WWW browser 70 
displays a profile creation screen 99 at block 808. 

FIGURES. 10A and 10B are illustrative of a profile creation screen 99 
(block 808) displayed by the WWW browser 70 on the document browser 
computer 30 for completing an initial user profile. With reference to FIGURE 10A, 
an illustrative profile creation screen 99 includes a portion 100 for the user to enter 
his or her initial contact information such as first and last name 102, a contact e-mail 
address 104, a user ED 106 and a password 108. In an actual embodiment, the first 
portion 100 entails the minimum amount of information required to be entered by the 
user to have a registration. As would be readily understood by one skilled in the art, 
the amount and type of data required in the initial user registration would vary 
dependent on the type of user and the services intended purpose. 

In a second portion 110 of the profile creation screen 99, the user indicates 
the level of security the user wishes to assign his or her profile information. In one 
actual embodiment, the user is presented with a choice of a limited, moderate or 
extensive privacy guard of the user information. The indication of one of these three 
levels will be then used by the fill server 34 to determine whether a form field will be 
automatically completed dependent on the proposed use by the form vendor. For 
example, some proposed uses of profile information include for personalization of a 
Web site, for completion of an activity such as an e-commerce transaction or for 
system administration. If a user selects an extensive security level, the fill server 34 
would be prevented from using the user's profile to complete fields for Web site 
personalization, but could use the profile for completing fields required to effect an 
electronic transaction. As would be readily understood, various security 
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